---
title: Entry Points
sort: 1
contributors:
  - TheLarkInn
  - chrisVillanueva
  - byzyk
  - sokra
  - EugeneHlushko
  - Zearin
  - chenxsan
  - adyjs
  - anshumanv
  - ritikbanger
---

As mentioned in [Getting Started](/guides/getting-started/#using-a-configuration), there are multiple ways to define the `entry` property in your webpack configuration. We will show you the ways you **can** configure the `entry` property, in addition to explaining why it may be useful to you.

## Single Entry (Shorthand) Syntax

Usage: `entry: string | [string]`

**webpack.config.js**

```javascript
module.exports = {
  entry: './path/to/my/entry/file.js',
};
```

The single entry syntax for the `entry` property is a shorthand for:

**webpack.config.js**

```javascript
module.exports = {
  entry: {
    main: './path/to/my/entry/file.js',
  },
};
```

We can also pass an array of file paths to the `entry` property which creates what is known as a **"multi-main entry"**. This is useful when you would like to inject multiple dependent files together and graph their dependencies into one "chunk".

**webpack.config.js**

```javascript
module.exports = {
  entry: ['./src/file_1.js', './src/file_2.js'],
  output: {
    filename: 'bundle.js',
  },
};
```

Single Entry Syntax is a great choice when you are looking to quickly set up a webpack configuration for an application or tool with one entry point (i.e. a library). However, there is not much flexibility in extending or scaling your configuration with this syntax.

## Object Syntax

Usage: `entry: { <entryChunkName> string | [string] } | {}`

**webpack.config.js**

```javascript
module.exports = {
  entry: {
    app: './src/app.js',
    adminApp: './src/adminApp.js',
  },
};
```

The object syntax is more verbose. However, this is the most scalable way of defining entry/entries in your application.

T> **"Scalable webpack configurations"** are ones that can be reused and combined with other partial configurations. This is a popular technique used to separate concerns by environment, build target, and runtime. They are then merged using specialized tools like [webpack-merge](https://github.com/survivejs/webpack-merge).

T> You can pass empty object `{}` to `entry` when you have only entry points generated by plugins.

### EntryDescription object

An object of entry point description. You can specify the following properties.

- `dependOn`: The entry points that the current entry point depends on. They must be loaded before this entry point is loaded.
- `filename`: Specifies the name of each output file on disk.
- `import`: Module(s) that are loaded upon startup.
- `library`: Specify [library options](/configuration/output/#outputlibrary) to bundle a library from current entry.
- `runtime`: The name of the runtime chunk. When set, a new runtime chunk will be created. It can be set to `false` to avoid a new runtime chunk since webpack 5.43.0.

- `publicPath`: Specify a public URL address for the output files of this entry when they are referenced in a browser. Also, see [output.publicPath](/configuration/output/#outputpublicpath).

**webpack.config.js**

```javascript
module.exports = {
  entry: {
    a2: 'dependingfile.js',
    b2: {
      dependOn: 'a2',
      import: './src/app.js',
    },
  },
};
```

`runtime` and `dependOn` should not be used together on a single entry, so the following config is invalid and would throw an error:

**webpack.config.js**

```javascript
module.exports = {
  entry: {
    a2: './a',
    b2: {
      runtime: 'x2',
      dependOn: 'a2',
      import: './b',
    },
  },
};
```

Make sure `runtime` must not point to an existing entry point name, for example the below config would throw an error:

```javascript
module.exports = {
  entry: {
    a1: './a',
    b1: {
      runtime: 'a1',
      import: './b',
    },
  },
};
```

Also `dependOn` must not be circular, the following example again would throw an error:

```javascript
module.exports = {
  entry: {
    a3: {
      import: './a',
      dependOn: 'b3',
    },
    b3: {
      import: './b',
      dependOn: 'a3',
    },
  },
};
```

## Scenarios

Below is a list of entry configurations and their real-world use cases:

### Separate App and Vendor Entries

**webpack.config.js**

```javascript
module.exports = {
  entry: {
    main: './src/app.js',
    vendor: './src/vendor.js',
  },
};
```

**webpack.prod.js**

```javascript
module.exports = {
  output: {
    filename: '[name].[contenthash].bundle.js',
  },
};
```

**webpack.dev.js**

```javascript
module.exports = {
  output: {
    filename: '[name].bundle.js',
  },
};
```

**What does this do?** We are telling webpack that we would like 2 separate entry points (like the above example).

**Why?** With this, you can import required libraries or files that aren't modified (e.g. Bootstrap, jQuery, images, etc) inside `vendor.js` and they will be bundled together into their own chunk. Content hash remains the same, which allows the browser to cache them separately thereby reducing load time.

T> In webpack version < 4 it was common to add vendors as a separate entry point to compile it as a separate file (in combination with the `CommonsChunkPlugin`). <br /><br /> This is discouraged in webpack 4. Instead, the [`optimization.splitChunks`](/configuration/optimization/#optimizationsplitchunks) option takes care of separating vendors and app modules and creating a separate file. **Do not** create an entry for vendors or other stuff that is not the starting point of execution.

### Multi-Page Application

**webpack.config.js**

```javascript
module.exports = {
  entry: {
    pageOne: './src/pageOne/index.js',
    pageTwo: './src/pageTwo/index.js',
    pageThree: './src/pageThree/index.js',
  },
};
```

**What does this do?** We are telling webpack that we would like 3 separate dependency graphs (like the above example).

**Why?** In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do things like using [`optimization.splitChunks`](/configuration/optimization/#optimizationsplitchunks) to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the number of entry points increases.

T> As a rule of thumb: Use exactly one entry point for each HTML document. See the issue [described here](https://bundlers.tooling.report/code-splitting/multi-entry/#webpack) for more details.
